CruiseControl.NET : SCM Policy

Source Control

CruiseControl.NET uses the Subversion Source Control server offered by SourceForge.net. Subversion access details for the project can be seen here .

CruiseControl.NET is tagged on every successful build by its own Continuous Integration process. These tags have a name related to the build number so look like (for example) https://ccnet.svn.sourceforge.net/svnroot/ccnet/tags/ver-1_0_0_1201.

CruiseControl.NET uses branches only to allow stable releases to be maintained while at the same time offer mainline iterative development. We use the release branching method, as described very well by the book Pragmatic Source Control Using Subversion . This means that if we have a release branch active we may decide to fix bugs on that branch, and then merge changes to the trunk. Apart from in extreme circumstances (and occasionally at the start of a branch) we never merge from the trunk to the branch.

Working on the Trunk

Working on the Branch

A release branch should only be used when both of the following cases are true:

A release branch is currently active for changes

The change is absolutely required as part of a new release off the branch

Working on the release branch is slightly more complicated that working on the trunk. The following examples are using the cvs command line and the first CruiseControl.NET release branch called RB_1_0 :

Check out the branch to a separate working directory : https://ccnet.svn.sourceforge.net/svnroot/ccnet/branches/RB_1_0

OR if you have already checked out the branch, make sure it is clean and up to date. Please try not to checkin more than one logical change to the branch at once since it makes tracking merges back to the trunk a nightmare

Make your changes in this directory

Commit as normal

Once your change has passed in CCNetLive, you need to merge your changes back to the trunk .

To do this, do the following:

Make sure you have a clean working directory of the trunk which is up-to-date and as no pending changes (if necessary check out a new working directory somewhere else on your machine)

Perform a merge in the root of your CCNet Trunk working directory. Apply the changes from the repository revision number that relates to your checkin to the branch and the revision before.

Example
If your changes appeared in revision 2396, you would use the following merge recipe:
svn merge -r2395:2396 https://ccnet.svn.sourceforge.net/svnroot/ccnet/branches/RB_1_0

Example
If you use TortoiseSVN, click merge on the top level directory of trunk. In the "From" box select the branch url, then click the topmost Show log button. Pick the revision number you want to merge in. Tortoise automatically fills in the rest of the dialog - so then click OK.

Run a local build! You need to make sure that your merge has worked on the trunk so don't go blindly committing.

Commit, mentioning in your commit message that you have done a merge, and what versions you merged

Example
CCNET-570 - cctray displays "Project is not automatically triggered" if the no next build date is set
(merged from 1.0, revision 2396)

Check CCNetLive that your build has passed and that the files that have been committed are exactly those included in the change to the branch

Branching History

Branch

Active?

Date Created

Label Immediately Before Branch

Comment

Date Retired

RB_1_0

2005-09-29

ver-1_0_0_1171

Version 1.0 Release Branch

Creating a new branch

First make sure that the all changes to the trunk have built successfully. Then, using the svn command line, issue the following command in a trunk working directory:

Finally, update the Branching History table above, making note of the label created by the last CCNetLive build.